ASCII text
title: GTK 4 makes no sense topics: ["gtk", "software", "opinion", "gnu/linux", "python", "c", "c++"] DATE: 2025-03-04 ---
I recently started to write a GTK 3 library, but then I realised it will be obsolete in 5 years at most, and I thought GTK 4 isn't that bad, so I decided to port it to GTK 4. Turns out I was wrong.
GNOME's hate for other desktops
GTK 4 clearly is made to reflect GNOME's vision of the future of desktops. Future versions will even require a "platform library", meaning your app will have to be tied to either GNOME, Elementary or whatever. In GNOME's vision, there won't be any generic apps.
GNOME should understand that I don't want to design anything, or make my app feel like an Apple product. Rather, I value more the users' comfort when using the app, which is increased when the app looks like the rest of the system and can be themed to fit the user's preferences or needs.
I've seen suspiciously few apps that use GTK 4 and not libAdwaita (and "adwaita" means "the only one" in Sanskrit, a fitting name for GNOME's design). Also, Cinnamon/Linux Mint, MATE, Xfce and other GTK desktops have not shared plans for a migration when GTK 4 has been out for 4 years already. This is a clear indication they're unsatisfied with GNOME, and GNOME is hostile to them.
The new "menus"
GTK 4 removed the traditional menus, because GNOME doesn't need them, as their apps are too basic (even thought of a division app marketed as a coffee tool)?.
They are now expecting powerful app developers to replace their menus with "menus" implemented with a popover. Some shortcomings of this approach:
The submenu handling
By default, sub"menus" aren't handled like they were before, where hovering its
parent would open the sub"menu", making it easy to browse through the options.
Now, you have to click the parent, which will slide the sub"menu" into view,
replacing the parent, and then, should you want to go back, you have to click
a back arrow. I guess this is probably intended for phones, where it could be
useful indeed as the screen is small you can't hover, but it should have been
a global preference in gsettings, not something the app developer has to
choose.
Even though you can opt for the classic "menu" behaviour, it's not the default, making apps like Inkscape use a wrong design. Having this at the DE level would make it so much easier for the user, the app developer, and the distributor.
Additionally, there are many other problems.
The menu construction
Now, to construct "menus", you have to use a GMenu object. Among other things,
this means your "menu" items can no longer be accessed as widgets. Instead, the
"menu" is declaratively constructed from a tree-like structure. This is a good
idea, but it has some flaws; every "menu" item must now be bound to a GAction,
which must have a string ID. Now instead of just managing your variables, you
have two namespaces to manage. When many items are similar to each other or even
dynamic (think zoom levels, move targets in a file manager, or a list of drives),
it's a pain to have to think of a unique ID for each one.
Why isn't there just a way to bind a "menu" item to a (lambda) function? This would make it so much easier to manage, and more flexible.
No more containers
GTK 4 removed containers and all related APIs with them. Now, everything is inconsistent, and you can't even have a signal when children are added or removed. Instead, if you want some other widget to sync with the children of a container, you have to subclass that container and override its add/remove methods so they emit custom signals. If the specific type isn't under your control, good luck.
Lots of functions, including Gtk::Box::pack_start, Gtk::Box::pack_end, and
others, were renamed to append and prepend for no reason. Also, you can no
longer get a vector of children from a container, you have to iterate over them
manually.
No Glade
Glade was a great tool and it's a shame to see it go. Cambalache exists, but
it's got its own problems, especially that the conversion from its own file to
a .ui file is one-way.
The alternative isn't a design tool, I don't want to design anything, but just to declare the layout and the signals, which the GtkBuilder still does well, writing XML by hand is just cumbersome though.
The good parts
I did decide to use GTK 4 because it has many benefits if you don't use it with libAdwaita:
Cell renderers have been deprecated, making everything use the same widget model.
CSS syntax has been updated to newer standards.
Drag and drop now makes much more sense.
No more padding properties which duplicated CSS's job.
Widgets are initially shown; you don't need to manually
show()them.GtkFileChooserNativewould allow the system's file browser to be used in all apps; more distribution support is needed though.All widgets now receive all events.
1
---
2
title: GTK 4 makes no sense
3
topics: ["gtk", "software", "opinion", "gnu/linux", "python", "c", "c++"]
4
DATE: 2025-03-04
5
---
6
I recently started to write a GTK 3 library, but then I realised it will be
8
obsolete in 5 years at most, and I thought GTK 4 isn't that bad, so I decided to
9
port it to GTK 4. Turns out I was wrong.
10
GNOME's hate for other desktops
12
-------------------------------
13
GTK 4 clearly is made to reflect GNOME's vision of the future of desktops.
15
Future versions will even require a "platform library", meaning your app will
16
have to be tied to either GNOME, Elementary or whatever. In GNOME's vision,
17
there won't be any generic apps.
18
GNOME should understand that I don't want to design anything, or make my app
20
feel like an Apple product. Rather, I value more the users' comfort when using
21
the app, which is increased when the app looks like the rest of the system and
22
can be themed to fit the user's preferences or needs.
23
I've seen suspiciously few apps that use GTK 4 and not libAdwaita (and "adwaita"
25
means "the only one" in Sanskrit, a fitting name for GNOME's design). Also,
26
Cinnamon/Linux Mint, MATE, Xfce and other GTK desktops have not shared *plans*
27
for a migration when GTK 4 has been out for 4 years already. This is a clear
28
indication they're unsatisfied with GNOME, and GNOME is hostile to them.
29
* [GNOME closing an issue about menus, saying it's a discussion, but it's not](https://gitlab.gnome.org/GNOME/gtk/-/issues/2922)
31
The new "menus"
33
---------------
34
GTK 4 removed the traditional menus, because GNOME doesn't need them, as their
36
apps are too basic (even thought of a [division app marketed as a coffee tool](https://flathub.org/apps/com.konstantintutsch.Caffeine))?.
37
They are now expecting powerful app developers to replace their menus with
39
"menus" implemented with a popover. Some shortcomings of this approach:
40
### The submenu handling
42
By default, sub"menus" aren't handled like they were before, where hovering its
44
parent would open the sub"menu", making it easy to browse through the options.
45
Now, you have to click the parent, which will slide the sub"menu" into view,
46
replacing the parent, and then, should you want to go back, you have to click
47
a back arrow. I guess this is probably intended for phones, where it could be
48
useful indeed as the screen is small you can't hover, but it should have been
49
a global preference in `gsettings`, not something the app developer has to
50
choose.
51
Even though you can opt for the classic "menu" behaviour, it's not the default,
53
making apps like Inkscape use a wrong design. Having this at the DE level would
54
make it so much easier for the user, the app developer, and the distributor.
55
Additionally, there are many other problems.
57
### The menu construction
59
Now, to construct "menus", you have to use a `GMenu` object. Among other things,
61
this means your "menu" items can no longer be accessed as widgets. Instead, the
62
"menu" is declaratively constructed from a tree-like structure. This is a good
63
idea, but it has some flaws; every "menu" item must now be bound to a `GAction`,
64
which must have a string ID. Now instead of just managing your variables, you
65
have two namespaces to manage. When many items are similar to each other or even
66
dynamic (think zoom levels, move targets in a file manager, or a list of drives),
67
it's a pain to have to think of a unique ID for each one.
68
Why isn't there just a way to bind a "menu" item to a (lambda) function? This
70
would make it so much easier to manage, and more flexible.
71
No more containers
73
------------------
74
GTK 4 removed containers and all related APIs with them. Now, everything is
76
inconsistent, and you can't even have a signal when children are added or
77
removed. Instead, if you want some other widget to sync with the children of a
78
container, you have to subclass that container and override its add/remove
79
methods so they emit custom signals. If the specific type isn't under your
80
control, good luck.
81
Lots of functions, including `Gtk::Box::pack_start`, `Gtk::Box::pack_end`, and
83
others, were renamed to `append` and `prepend` for no reason. Also, you can no
84
longer get a vector of children from a container, you have to iterate over them
85
manually.
86
No Glade
88
--------
89
Glade was a great tool and it's a shame to see it go. Cambalache exists, but
91
it's got its own problems, especially that the conversion from its own file to
92
a `.ui` file is one-way.
93
The alternative isn't a design tool, I don't want to design anything, but just
95
to declare the layout and the signals, which the GtkBuilder still does well,
96
writing XML by hand is just cumbersome though.
97
The good parts
99
--------------
100
I did decide to use GTK 4 because it has many benefits if you don't use it with
102
libAdwaita:
103
* Cell renderers have been deprecated, making everything use the same widget
105
model.
106
* CSS syntax has been updated to newer standards.
107
* Drag and drop now makes much more sense.
108
* No more padding properties which duplicated CSS's job.
109
* Widgets are initially shown; you don't need to manually `show()` them.
110
* `GtkFileChooserNative` would allow the system's file browser to be used in all
111
apps; more distribution support is needed though.
112
* All widgets now receive all events.
113